Previous Page TOC Next Page



- 12 -
DDE and OLE


Dynamic data exchange (DDE) and object linking and embedding (OLE) are both methods for sharing data between documents. Of the two, DDE is older. OLE actually has two versions. (A third form of OLE—Network OLE—wasn't incorporated into this version of Windows NT, but you'll see it in the next version because most Internet servers will need this capability.) Windows NT supports the newer OLE 2 standard, but that doesn't mean your applications will. A lot of people know what the acronym means—perhaps they even use OLE from time to time—but they can't understand what all the hubbub is about. After all, it's just another form of cut and paste—or is it? The first thing you need to understand about OLE is that it's not just cut and paste. In most of the chapters in this book, I've talked about the objects Windows NT uses to make life simpler for the user. Would it surprise you too much to learn that these objects are a form of OLE support?

Objects (not object orientations) can really make your documents easier to use and maintain if you use them correctly. At first, it'll seem as if there are a lot of rules to follow. After you learn the rules of the road, though, you'll find that you can create very complex documents in a lot less time (and with far better results) than before.

I want to get one of the ground rules out of the way: OLE isn't the technology to use on a simple document. If the only thing you plan to do is create a word processed memo or some other small document, you're probably right in thinking that OLE is a waste of time. The more complex the document becomes, however, the greater the benefit of using OLE.

Compound Documents: The Microsoft Strategy


You need to speak the language of OLE to really understand it. The following list defines some of the terms you'll see in this chapter (and the chapters that follow).

Now that you have some idea of what these OLE terms mean, take a look at some actual examples. I used Microsoft Paint and WordPad for my example so that you could follow along if you want to. It isn't really necessary to do so; the important thing is that you understand the process.

The first thing I did was double-click a BMP file—Honeycomb—in the main Windows folder. Then I opened a copy of WordPad. You should see something similar to Figure 12.1. There isn't anything particularly special about these two applications, but they do both support OLE 2, which will enable me to show you some of the things you can look forward to.

Figure 12.1. Using OLE starts with something as simple as opening two applications.

Choose the Edit | Select All command in Paint to select the entire image and then right-click it. You should see the object menu shown in Figure 12.2. Notice that you can't drag and drop this image because Paint doesn't support that particular OLE 2 feature. If it did support drag and drop, you could simply right-click the object and drag it where you wanted it to go in WordPad. You'll need to take a somewhat longer route.

Figure 12.2. This object menu contains options that enable you to place the object on the ClipBoard.

The object menu enables you to cut or copy the image. Notice the number of other editing options this menu contains. You might want to make note of what's available and compare it to the object menu after you copy the image to WordPad. For right now, choose the Copy option. Doing so places a copy of the object on the ClipBoard.



Note: You can use the Edit | Paste Special command in place of the object menu when working with WordPad (or other applications that provide this feature). In fact, some applications don't provide an object menu, so you have to resort to using the Edit menu. I'll demonstrate this method of linking or embedding an object later in the chapter.

Click in WordPad to bring it forward. Right-click anywhere within the window. You should see an object menu similar to the one in Figure 12.3. Notice how this menu differs from the one you saw in Paint. Each object menu will have features unique to that application. A graphics application needs menu entries to help it manipulate graphics images. A word processor needs a different set of options to manipulate text.

Figure 12.3. The WordPad object menu differs from the one found in Paint because it needs to perform different work.

Choose the Paste option from WordPad's object menu. You should see a copy of the graphics image in WordPad, as shown in Figure 12.4. The first thing you should notice is the sizing handles around the image. These handles enable you to enlarge or shrink the object as needed. This feature is really handy in some cases. When I need to draw a logo, for example, I usually draw it very large. That way, I can get it done quickly without worrying too much about detail. When I paste the logo into a document, I shrink it to the size I really need it to be. Voilã—instant detail. As you shrink the graphic, it actually gains some amount of detail you usually wouldn't get if you drew the image that size.

Figure 12.4. The pasted object always provides sizing handles when you select it.

Now that the image is stored in WordPad, go ahead and close Paint. You can always open it again if you need it later. If you right-click the graphics object, you'll see a menu similar to the WordPad object menu you saw earlier. Notice the two bottom options: Bitmap Image Object and Object Properties. Highlight Bitmap Image Object to display a submenu.

The two options here are Edit and Open. The difference between them is distinct. You choose Edit if you want to perform in-place editing. The Open option actually opens a copy of Paint, which you can use to edit the graphic. To see what I mean, choose Edit now. You should see a display similar to Figure 12.5 with quite a few changes. For one thing, there's a hatched box around the object. This is an OLE 2 way of telling you which object you're currently editing. Also notice that the toolbar and menus changed to match those of Paint. This is what I mean by in-place editing. The window didn't change, but the tools did to meet the editing needs of the object.

Figure 12.5. In-place editing is one of the new OLE 2 features.

You can click anywhere outside the object to restore the original WordPad menu and toolbar. Select the Open option to see what happens. You should see a display similar to Figure 12.6, which provides you with some visual cues. The most obvious is that you're editing the graphics object outside WordPad using the originating application. The method you use is largely dependent on personal taste, because the result of using either method is the same. The advantage of using the in-place method is that you remain in the same window all the time. This tends to increase efficiency and reduce the chance of losing your train of thought. The Open method has the advantage of returning you to the native editing environment. If I chose to edit one of my logos instead of opening it, I would have to perform in-place editing on a much smaller version of my original picture. Of course, I could always resize it to its original state, but that would be as inefficient as any other method—perhaps more so. Notice also that the object is hatched over in WordPad. This is another visual cue telling you which object you're editing externally.

The Open method does require one extra step. You need to tell Paint to update the copy of the graphic that's still in WordPad. Choose File | Update Document, as shown in Figure 12.7. Notice how this option replaces Save. In essence, the update process does save the graphic; the only difference is where the graphic gets saved.

Figure 12.6. Choosing the Open option produces an entirely different result from choosing Edit.

Figure 12.7. Make certain that you update your document before you leave the server application.

Exit Paint and return to WordPad. Notice that the Exit entry on the File menu also says Return to Document. Check out what that other object menu entry contains. Right-click the graphics object and choose the Object Properties option. You should see the Bitmap Image Properties dialog box shown in Figure 12.8. About the only interesting entry on the General page is the Convert button. Clicking this displays another dialog box with a list of conversion options. In essence, this option enables you to convert the graphics object from one file type to another. This page also displays the file size and type.

Figure 12.8. The General page of the Bitmap Image Properties dialog box provides access to the Convert dialog box.



Note: Each object type provides a unique set of pages in the object dialog box. It's important to remember that each dialog box reflects a combination of the capabilities of the server applications and the needs of the data file format. Some file formats can't support some application features. As a result, some options might appear grayed out.

Click the View tab. You'll see the View page of the Bitmap Image Properties dialog box, shown in Figure 12.9. This page has several interesting entries. The first is the radio button that determines whether the image is displayed as a graphic or an icon. You can make your machine run faster and use less memory if you select the icon option. Using an icon means that Windows doesn't need to load the actual image or the application required to support it unless you decide to edit it. Windows will suggest a default icon, but you can use the Change Icon button to select another.

Figure 12.9. The View page of the Bitmap Image Properties dialog box enables you to change the appearance of the object.

The bottom part of this dialog box is fairly interesting too, even if you can't select it at the moment. It enables you to select a precise scale to use when displaying your graphic. The BMP format and application used to display it doesn't support the scaling option in this particular case. Close WordPad; you don't need it anymore for now. You don't have to save the image unless you want to.

This whirlwind tour presented some of the things you can look forward to with OLE 2. Of course, you haven't even come close to exercising every feature yet. Now it's time to take a step back into the past to examine some of OLE's roots. The next section talks a bit about DDE before I proceed with the discussion of OLE.

Dynamic Data Exchange (DDE) Overview


"The King is dead; long live the King!" (I just had to say that.) A lot of people have the mistaken idea that DDE is dead. Oh, it used to be the way to transfer data between applications, but OLE is the way to go today. There's only one thing I want to say. If DDE is so dead, why does it keep popping up in the registry? Even Explorer, an application designed for Windows 95 (and incorporated into Windows NT), provides DDE capability. The fact is that every OLE application uses a little DDE to make it run. I use the term "uses" here because OLE 2 might actually make DDE a thing of the past, but I'll look at that later.

Now that I have your attention, take a look at DDE. Using DDE has some significant problems. The most significant is that it creates a static link, much like the one you get using cut and paste. The fact that it provides a stable macro language that you can use to open files and perform other fancy maneuvers from the command line doesn't change the situation much.

DDE is a messaging protocol. It sends a message from one application to another and asks it to do something. Originally, DDE was supposed to provide the means to open another application and copy some data to the ClipBoard. You could also get it to do other chores, such as printing files. A DDE macro contains part DDE and part application macro language, which presents another problem. Not only do you need to learn the native language of the application you're using and DDE itself, but you also have to learn the macro language for the server application. Needless to say, DDE didn't get the kind of reception Microsoft originally hoped it would. DDE is simply too complicated for the average user to consider using. In fact, even some programmers find it difficult to use (unless they use it on a regular basis).

OLE automation (part of what OLE 2 is supposed to eventually deliver) will reduce or eliminate the need for DDE sometime in the future. One of the features OLE automation provides is a consistent macro language—the same macros work with every application. This means that a programmer could create a macro for an application that he doesn't even have loaded on his machine.

The problem with OLE is that very few applications actually support OLE 2 and even fewer support OLE automation. I have three applications that support OLE automation on my machine right now—that's three out of 20 or so. Considering that I have all the newest versions of everything on the market, that's not a very inspiring level of conformity.

Another problem with OLE that Microsoft hopes to solve soon is that you can't use it across a network. DDE works just fine in this situation. In fact, products like Artisoft's LANtastic make use of this feature in utility programs such as their DDE Link Book. A future version of Windows will include something called Network OLE—a new type of OLE designed to create network links. Microsoft is getting a lot of pressure to provide Network OLE right now, because people need it to get their Internet servers up and running—but more about that later.

DDE Programming Tips


In the previous section, I mentioned that DDE programming required a knowledge of the client application's DDE macro programming language and the server application's macro language. There's actually a little more to it than that. You have to understand how the ClipBoard fits into the picture as well. I'll repeat myself by stating that DDE programming is probably one of the more difficult things to master under Windows.

Just to give you an idea of how difficult DDE can be to understand, the following code segment shows a short macro I created for 1-2-3. DDE is anything but user friendly. I've seen low-level languages that provide more information than this one does. All this application does is place a copy of LEAVES.BMP in a Word document and then create a link to that file in 1-2-3. Notice that I'm creating an OLE link using DDE; if this version of 1-2-3 supported OLE automation, I would take a much easier route to accomplish this task. The amazing thing is that I actually got this to work. In essence, 1-2-3 is controlling Word.


{LAUNCH "D:\WIN\WINWORD\WINWORD"}

{DDE-OPEN "WINWORD","SYSTEM"}

{DDE-EXECUTE "[InsertObject .IconNumber = 0,

[ccc] .FileName = ""D:\WIN95\LEAVES.BMP"",

.Link = 1, .DisplayIcon = 0, .Tab = ""1"", .Class = ""Paint.Picture"",

.IconFilename = """", .Caption = ""LEAVES.BMP""]"}

{DDE-EXECUTE "[CharLeft 1, 1]"}

{DDE-EXECUTE "[EditBookmark .Name = ""DDE_LINK1"", .SortBy = 0, .Add]"}

{SELECT A1}

{LINK-CREATE "LINK1";"Word.Document.6";"Document1";

[ccc]"DDE_LINK1";"Picture";"Automatic"}

{LINK-ASSIGN "LINK1";"A:A1"}

The first line of this mini-application launches Word for Windows. DDE sends a message to Explorer, telling it to start Word. After Explorer completes this task, it sends a completion message back to the DDE server. The next line opens Word as a DDE server. Even though Word is running, the DDE server won't know it exists until it gets a message from your application. The third, fourth, and fifth lines are the most difficult to understand. They tell Word to insert a copy of LEAVES.BMP into the current document. (The third, fourth, and fifth lines are actually one line of the DDE macro. You usually wouldn't see them this way; I had to split the macro instruction to make it fit in the book.) The sixth line tells Word to highlight the image, just like you would by clicking it with the mouse. The seventh line creates a bookmark. Now, you might wonder why I would do all this just to assign a bookmark to an object I embedded in Word, but you'll find out in a second. The eighth line places the 1-2-3 cursor in the upper left corner. The next line is very important. It assigns the object I created in Word to a link in 1-2-3. The final line makes that link a reality.

By now, you're asking yourself why I would go through all this trouble just to link a BMP file to a 1-2-3 worksheet. To answer that question, you'll have to experiment a little. I think you'll find it pretty tough to create the same kind of link the DDE procedure does without performing this procedure manually. Just try it sometime. OLE just doesn't provide all the features you need to create every type of link you'll need, and it certainly doesn't enable you to create those links as part of a macro or program. (OLE automation should change that in the future, but it isn't here today.) The automatic method allows me to place logos in my worksheets with a minimum of effort. As you can see, learning DDE is a requirement if you plan to create automated links in macros and other types of programs.

How can you make your DDE programming experiences a bit easier? I find that you can use several techniques to make things at least palatable. You still won't like DDE programming—I don't think anyone does—but the following techniques will reduce the amount of time you spend getting up and running. Obviously, they are only a stop-gap measure until OLE automation and Network OLE get off the ground. I'm hoping that in the next two or three years, I'll finally be able to kiss DDE good-bye.

You usually don't need to worry about the vagaries of DDE programming when using OLE. In fact, the initial example in this chapter shows what a typical OLE session is like. The DDE section showed you what goes on in the background—the part of OLE you don't usually see. I don't want to discuss all the fine points of OLE programming here. If you really do want to get started in OLE programming, however, you'll need a copy of the OLE SDK from Microsoft. This package includes a heavy duty CD and a rather large and cumbersome book. The fine points of OLE programming are so esoteric that I really doubt that anyone understands all of them completely.

ClipBook Primer


Using the ClipBoard to transfer information between applications has a lot of problems. Because OLE uses the ClipBoard a lot, it pays to know what those problems are. One of the biggest issues is that the ClipBoard supports only one file at a time—a pretty severe limitation when you think about it. Another problem is that you can't share your ClipBoard with network users—at least not unless you save the ClipBoard to a file using the ClipBoard Viewer utility and then send the file to someone else on the network. (This is a manual connection—not automatic—so you can't pass OLE data over the network using it.) Of course, that brings up the last problem: trying to remember what you've stored in all those ClipBoard files as you trudge through them one at a time.

ClipBook appeared for the first time as part of Windows for Workgroups as a means to store the contents of more than one ClipBoard at a time in one file. ClipBook offers a lot more than just a method for storing more than one page of ClipBoard data, though. For one thing, you can connect to other workstations and borrow their ClipBook pages. You can also decide whether you want to share your ClipBook pages with other people.

I want to take some time to discuss ClipBook's features. You'll find that ClipBook uses the idea of a book to get the job done; each entry is treated as a single page. It enables you to store up to 127 pages in one ClipBook file. That's like having 127 copies of the ClipBoard around. Each page can contain a completely different kind of information, and ClipBook provides a variety of viewers to look at the contents of those pages. Before you can create a new page, ClipBook asks you for a data description that can contain up to 47 characters. You also have a variety of ways to view your ClipBook pages, the most common view being the thumbnail view that provides you an overview of what each page in your ClipBook contains.

What is ClipBook doing in a chapter about OLE? You can use ClipBook to use OLE on a network—but it's not easy. It's not the same as having full Network OLE capabilities around; you won't see that until the next version of Windows NT. On the other hand, it's better than nothing at all. The secret is in ClipBook's capability to share data automatically across the network and start the remote application as soon as a client application requests data from it.

Don't get the idea that ClipBook provides the best connection you could possibly get. You're looking at a thread of communication so fragile that I'm often amazed it works at all. I think you'll find that ClipBook works fine as long as the users of both machines don't touch any of the files. ClipBook still stores the ClipBoard's data in CLP files. Damage to ClipBook's INI file or any number of other problems can damage the connection. Needless to say, moving the data on either machine is also a potential problem, as are any changes to the host machine's application configuration. As I said, ClipBook works, but only just barely. Still, it's your only option for creating network OLE links right now, and in that capacity, ClipBook is quite valuable.

I'm going to take you on a quick tour of ClipBook in the following sections. I'll concentrate on the OLE and general usage procedures for this utility. ClipBook does have a lot to offer, so you should take some time to get a good look at it.

Adding Pages to ClipBook


Adding a new ClipBook page is fairly easy. You start by copying something to the ClipBoard using the Edit | Copy command found in any application. Open the ClipBook application. All you need to do now is use the Edit | Paste command to start the process. (In case this doesn't sound familiar, it's similar to the process that you followed to create an OLE link in the first part of this chapter.) ClipBook displays a Paste dialog box, which includes a Share checkbox for you to specify whether you want to allow other people on the network to use your ClipBook data. You have to check this box to create an OLE connection on the network. After you enable the Share checkbox, type a description of the ClipBoard data; then, click OK to create the page.

At this point, you'll see a new page added to your ClipBook (if you decided not to share the data), or you'll see the Share ClipBook Page dialog box. ClipBook displays this dialog box whenever you decide to share your data with someone else. This dialog box has several options that affect how ClipBook acts when another computer tries to use the page you've created.

The Start Application on Connect checkbox tells ClipBook to automatically start the application that produced the data on the ClipBoard when another application tries to access the ClipBook page. You need to enable this option if you want to provide OLE services to another machine on the network. If the other machine can't automatically start the OLE application, the network link fails and the user gets an error message. (The only exception to this rule is if you just happened to be running the application at the time the other machine requests data from it.)

For security reasons, you probably want to limit access to the data. The two levels of access are read and full. Unless you plan on allowing the other person to modify the data, read access is sufficient. Full access enables the person to read and write the data on the ClipBook page. Always provide a password to protect the data; otherwise, anyone on the network will have free access to the data. You can also choose to allow both read or full access based on the password the user provides.

After you define all the options on the Share ClipBook Page dialog box, click OK to create the new page. You'll see one of three views of your data. Three buttons on the toolbar allow you to switch between the various views: Table of Contents, Thumbnail, and Full Page. The Table of Contents view simply shows a document symbol and the description you typed. A hand under the document symbol tells you that the document is shared. Highlighting the document and clicking the Share button on the toolbar enables you to change the various share options. Clicking the Stop Sharing button removes the hand from below the document symbol and prevents anyone from using that page.



Tip: You can double-click the ClipBook display area to switch from view to view. ClipBook shows each display type in turn as you double-click.

You can also use the Thumbnail view to look at your data. Like the Table of Contents view, it enables you to see as many ClipBook pages as will fit on-screen. The advantage to this view is that you get a better idea of what kind of data each page contains. The Thumbnail view shows a representation (albeit an unreadable one on most displays) of your data. The disadvantage is that you can't see as many pages as with the Table of Contents view.

Use the Full Page view when you need to see exactly what the data looks like. It shows only the data in the currently selected page. I usually use the Thumbnail view to find the page I want and then use the Full Page view to make sure that it's the right one. Usually, you'll want to use the Default Format option for viewing the data. ClipBook does offer several viewers for each data type, however. You can use one of these optional viewers to look at the data when the default viewer produces less than acceptable results.

Creating a Network OLE Connection


Now that I'm past all the usage details, take a look at how you can use ClipBook to create a network OLE connection. The first thing you need to do is create a connection to the host computer so that you can access its ClipBook pages (the shared ones). You probably have noticed the two buttons at the left end of the ClipBook toolbar. The first one makes a connection to the host computer. Click this button, and you see a Select Computer dialog box. I always keep the Always Browse checkbox enabled because I like to make things as easy on myself as possible. Checking this box displays a list of the computers on the network. All you need to do is select the one you want to establish contact.

After ClipBook establishes contact with the other computer, it displays its ClipBook within your ClipBook. This ClipBook tells you which computer you're using instead of indicating that it is a local machine.

To select some remote data for use, simply highlight the page you want and click the Copy button on the toolbar. This places the data on your local ClipBoard. All you need to do now is open the client application and use the Edit | Paste special command like you did to create an OLE object. You won't really notice any difference between the object created using this method and one created locally, except for the time required to start the remote application when you want to edit or open the object.



Tip: You'll find that your network OLE objects are a lot more stable if you embed the object rather than create a link to it. Because you can't assume that the other machine will always be available when you open the document, embedding the data makes more sense. Embedding also makes it less likely that a change in the remote machine's configuration will affect the OLE object. As with all links, remote links are very susceptible to damage if the original document gets moved. You have to factor in remote access problems that a local link doesn't have to contend with. The remote machine could get renamed, for example, making it impossible for you to reestablish contact. You'll also find that it's harder to link an object than it is to embed it. Even though the Link radio button is enabled in the Paste Special dialog box of the client application, it doesn't mean that you can actually create a link. Some remote server applications won't respond correctly if you try to create a link but will work fine if you embed the data.



Note: The remote OLE objects that you create using ClipBook aren't always as error free as local objects. Word for Windows documents often get misread as Formatted Text (RTF) instead, for example. Pay special attention when selecting a data type in the Paste Special dialog box of the client application.


Linking Versus Embedding


You saw the object part of object linking and embedding earlier. You had no doubt that what you were manipulating was an object and not merely a cut-and-paste example of the graphic. Now it's time to take a look at the linking and embedding part of the picture.



Peter's Principle: A Time to Link and a Time to Embed

Some people get confused about when it's appropriate to use linking versus embedding. I break the two down into simple categories so that it's easy to determine when to use each type of OLE. The main problem is defining precisely what kind of compound document you want to create.

Embedding works best when you need to share a file with a lot of people. If the compound document is going to move around, you want to package it in such a way that nothing gets lost. An embedded object meets this criterion. Even though embedding is less subject to data loss, it does have a disadvantage: You can't easily share with other people the data embedded within your document.

On the other hand, linking does work well in this instance. If you plan to use the same file in more than one place, linking is the route to go. I almost always use this technique instead of embedding when working with logos.


When you link a document, you are, in essence, creating a pointer to that file on disk. Think of a link as a road sign pointing to your house. As long as you don't move the house, everyone will be able to find it because the road sign will point them there. What happens if you do move the house, though? The sign still points to where it thinks your house is, but anyone who follows the sign will find nothing but an empty foundation.

The same principle holds true for links in compound documents. The link works fine as long as you don't move the document. The second you do move the document, though, you break the links. Of course, you can always reestablish the links, but that's a waste of time when not moving the file in the first place would require a lot less work.

OLE 1 had a significant problem in this regard because it noted the location of the linked file in precise terms. It would be the same as using your complete address to tell someone how to get to your house. Again, if you moved, the address information would do them little good. OLE 2 takes a different approach. Instead of using a precise location, it uses a relative direction. What if you told your friends that you lived two blocks south of Joe, for example? As long as you and Joe maintained the two-block distance, people would be able to find your house. (Of course, they would need to know the location of Joe's house.)

Embedding is a different process from linking. Instead of creating a pointer to your data, embedding actually places the data object within the compound document. This means that wherever the compound document goes, the data will follow. This sounds like a great fix for the problems with linking. Embedding comes with several price tags attached, however. First, you'll find it very difficult to update multiple compound documents at once. Suppose that your company just decided to use a different logo and they want all the letters updated to reflect that change. If you had linked the logo file to the letters, the change would be simple. You would need to change just one file. Anyone who opened each document after that would see the new logo. With embedding, you'd have to change each document on an individual basis.

You'll also use a lot more disk space to store an embedded file. A link takes only a few bytes to create a pointer. An embedded object is complete. If the object is 4KB, your compound document will grow by 4KB to accommodate it. Unfortunately, you won't get off that easily. In addition to the size of the object, some "housekeeping" data is included as well. The server needs this information to help you maintain the object.

Now that you know the difference between linking and embedding, take a look at how you would implement them. Begin by opening a copy of WordPad. I'm going to explain another route you can take to link and embed objects in your documents. Choose the Insert | Object command to display the dialog box shown in Figure 12.10. Notice that you can go two routes at this point: You can insert a new object or an existing one.

Click the Create From File radio button (the dialog box changes to the one shown in Figure 12.11). Choosing that option will allow you to embed or link an existing file. Click the Browse button and find any BMP file you like. Double-click to select it. Click the Link checkbox. If you don't enable this checkbox, Windows automatically embeds the object instead of linking it. Your dialog box should match the one shown in Figure 12.11. Notice the Display As Icon checkbox. Clicking this displays the object as an icon rather than as a full image.

Figure 12.10. Use the Insert Object dialog box to embed or link a new or existing object into your document.

Figure 12.11. Embedding or linking an existing file to your document.



Tip: Sometimes it's better to display an object as an icon. You'll probably want to use this option as you design a document to reduce the load on the processor, for example. Every object you keep open reduces your capability to create a document quickly because the client application has to keep calling on the server application to display the information. After you complete the document, you can disable the Display As Icon checkbox to show the object in its original format. This enables you to print the document—complete with objects—after you get done putting it together.

Click OK to place a link to the object in the current document. A quick glance at this object doesn't reveal anything different from the last time you created a compound document. When you right-click the object, however, you'll notice that the menu entries are slightly different. The big difference is obvious when you try to edit the file. Instead of the in-place editing you could do after embedding the object, editing a link always opens the server. You must edit the object in a separate window when using linked objects in place of embedded ones. If you really dislike seeing the other application start, you might want to use embedded rather than linked objects.

I hope you now completely understand the differences between linking and embedding. These differences are important for a lot of reasons. When there's a little overlap in functionality and it's acceptable to use either linking or embedding, select the method that appeals to you most. My favorite method is embedding because I prefer to use in-place editing when I can. From a practical standpoint, however, I often have to use linking now to reduce my workload later.

Clients and Servers


Every application that supports OLE provides one or more services. You might have noticed in all the examples that I used Paint as the server and WordPad as the client. The reason is simple: Paint can't function as a client. It offers itself only as an OLE server. (Some programs only function as a server, some only as a client, and still others as both.)

This distinction is important because it affects the way you use an application. More than that, limitations of OLE support necessarily limit an application's value for creating a finished product. Consider what would happen if you tried to use a graphics program to create a poster, but it didn't support OLE as a client. Would you simply settle for cut and paste if there were a chance you would need to modify the chart frequently? If Paint supported OLE as a client, you could create a chart for your poster in one application, the text in another, and the graphics elements in a third and then link them all together within Paint. The lack of client support means that you'd have to copy the text to the ClipBoard. When you pasted it into Paint, the text would become a graphics element—part of the Paint graphics image. The text wouldn't be an OLE object you could easily manipulate later using a word processor; it would be a graphics element you'd have to erase and redo from scratch. This makes changes as small as using a different type style or font size a lot more difficult than they need to be.

Whether your application is a client or a server is an important consideration. You might find that it's less expensive from a time-investment perspective to get rid of an application with limited OLE support. You can follow some general guidelines when it comes to choosing applications.

Any application that will serve as a central location for all the objects in a project must support OLE. In most cases, you'll want to use a word processor or presentation graphics program for this purpose. They provide the greatest amount of flexibility when it comes to formatting your data. Charts and graphs might need the services of a graphics program. Unfortunately, most low-end packages won't work as clients, so you'll need to invest in a high-end package such as CorelDRAW!. You'll definitely want a package of this sort to provide both client and server capabilities because you'll need to use both.

You can do quick-and-dirty edits with low-end packages. They usually have just enough features to get the job done and don't waste a lot of precious memory. Programs of this sort usually support OLE as a server but not as a client. No one would want the output from these programs; it just doesn't look professional. Microsoft Paint and other low-end graphics packages commonly fall into this category. You might see some note-takers here, too. In some cases, all you need is the text. A note-taker (such as the Notepad utility provided with Windows NT) works fine for this purpose.

Finally, you'll never use some packages as servers because they just don't generate enough data on their own to make it worth your while to use them in that capacity. Some presentation graphics programs fall into this category. Because their output looks nice, you can use them as OLE clients without worrying about their server capabilities.

Differences Between OLE 1 and OLE 2


Microsoft introduced OLE 1 as part of Windows 3.x. It provided a basic set of linking and embedding features that users soon outgrew. One of the biggest problems was the huge amount of memory OLE 1 required to create more than one or two links with other applications. OLE 1 required the client to start every application that it had established an OLE link with—whether or not that link was actually displayed on-screen. If you had links with a spreadsheet, a graphics program, and a charting program, all three would have to be in memory when you opened the compound document. Most machines just didn't provide that amount of memory. The lack of speed was also a major concern. Keeping all those applications going at once made a real performance hit; most machines spent their time swapping out one application to disk and swapping in another as you moved from place to place in the compound document. In addition, the way OLE 1 managed links was inefficient.



Note: As of this writing, Microsoft is working on Network OLE—a method for creating OLE objects over the network without the use of an intermediary such as ClipBook. In addition, Microsoft is working with the Object Management Group to create links between CORBA (common object request broker architecture) and COM (common object module). CORBA is the specification used by products such as OS/2; it's an OLE look-alike. COM is the specification for the underlying OLE architecture; it's what you're actually working with when you use objects. Other events, such as the release of a new OCX (OLE common control) specification named OCX96, point to more changes in OLE in the future. What does this mean to you as a user? It means that learning OLE now—especially the capabilities of the various programs you own—is an investment in the future. The more you read about upcoming events in the world of OLE, the more you'll come to understand that OLE is here to stay.

OLE 2 is supposed to remedy some of the OLE 1 problems and provide much more functionality to boot. The following list gives you an idea of all the improvements Microsoft made in OLE 2. Some of them are programmer specific, but everyone benefits from something that makes a programmer's life even a little easier.



Tip: Most of the following new features require that both applications support OLE 2. At the very minimum, the client must support OLE 2 in order to make any of the features work. I discussed the registry in Chapter 7, "Understanding the Windows NT Registry." Some vendors give you an idea of how to use OLE but don't really tell you how they support it. Looking in the registry can provide important clues as to the type and level of OLE support an application provides.

You might think that all the changes to OLE 2 would cause compatibility problems, but OLE 1 and OLE 2 can mix freely on your machine. When you examined the registry entries in Chapter 7, you saw that each application had a set of OLE 1 and OLE 2 entries. Compatibility is the reason for the dual set of registry entries. The important thing to remember is that OLE takes a least-common-denominator approach. Everything is tied to the application that has the fewest capabilities. This means that if you had four OLE 2 applications and one OLE 1 application, everything would be tied to the level of support provided by the OLE 1 application.

Application Interoperability


Getting two applications to work together might not always be as easy as it seems. You've already seen a lot of ways that two applications can differ in their implementation of OLE, but those examples barely scratch the surface. For the most part, I've discussed the standard ways that two applications can deviate. The following list gives you some ideas about what to investigate when you can't get your objects to work properly:

This list is just a sample of the types of problems you could encounter with a common setup. Add to these problems a vendor who doesn't fully support the OLE 1 or OLE 2 standard. I encountered one piece of software that ended up providing some strange cross of support between the two standards (and I don't think this vendor was alone). These support problems only make the situation worse. If every application supported OLE perfectly, you could probably get past the other problems I listed in this section. The combination of faulty support and less-than-adequate linking mechanisms does paint a grim picture for the user. It would be easy to point a finger and say that the vendor was totally at fault. Yet anyone who has tried to read the OLE standards, much less follow them, will attest to the level of difficulty involved.



Note: Just in case curiosity has you wondering, the OLE SDK disk weighs in at 129MB. That doesn't include all the documentation or even a compiler. (Documentation includes some white papers, a copy of the OLE 2 specification, and the complete text on OLE automation.) I also received another book with the kit that consumed another 975 pages and came with two additional floppy disks worth of sample programs. Talk about a lot of information to learn! When you consider that OLE isn't the entire application—it's only a small piece of an application—would you be willing to spend the time required to go through all this material?

Before you get the idea that all is lost with OLE, I want to inject a dose of reality. I wanted you to be aware of all the problems you might find, but in most cases, I don't have any substantial problems with OLE that I didn't cause myself. Sure, sometimes I would like to be able to do more than the applications I'm using will allow, but these are inconveniences; they don't make OLE unusable. The best thing you can do when using OLE is to thoroughly check everything before you make a huge commitment in time and energy to a specific solution. It always pays to check for potential pitfalls, and this is especially true of a technology as new and complex as OLE.

Packaging OLE Objects


OLE wasn't the smashing success Microsoft hoped it would be when they first introduced it on the market, and I've already discussed some of the reasons. Part of Microsoft's answer to the problem of a lack of OLE support was Object Packager, which comes with Windows. You can still find this utility in your main Windows directory, but you won't see it on your Start menu. I added my copy to the Start menu to make it easier to access.

Object Packager is good for only one thing: It enables you to create a package you can insert into a document. The result is similar to an object you create using the native capabilities many programs provide today. It's a good utility to keep around for those older applications that don't directly support OLE.

Instead of boring you with a lot of details about this particular product, I'll put a package together. In fact, I'll use the same two applications I've used throughout this chapter, along with the same data file. This will allow you to see the difference between an object package and an object.

The first thing you need to do is create the object package. Open Object Packager. You should see the display shown in Figure 12.12. A lot of people claim this utility is difficult to use. Actually, they're only half right. This utility isn't all that hard to use; it's the documentation that makes using it seem difficult.

Figure 12.12. Object Packager looks simple, and it really is once you get the hang of it.

Click the Insert Icon button. Object Packager automatically assumes that you want to use one of the icons out of Program Manager because it was designed for that interface. You can choose another icon using the Browse button, but I'll use one of the icons listed. After you select an icon, click OK to complete the task.

Choose the Edit | Label command to add a label to the icon. This will identify the file you plan to use. I typed HONEYCOMB.BMP, but you can use any other identification you choose.

The Edit | Command option enables you to add the location of the file you want to edit, along with the application that will perform the editing. You need to know the command-line syntax for the application in order to do anything fancy here. In most cases, you won't use Object Packager directly with an application that registers itself, so you will probably be limited to opening the file with the application. To do that, just type the name of the program followed by the file name, just like you would at the DOS prompt. I typed MSPAINT D:\WIN95\HONEYCOMB.BMP in this case. You can modify the contents of your command to meet the needs of a particular situation. Figure 12.13 shows the result of all the edits so far. Your display might look slightly different, depending on the choices you made.

Now that you have a completed package, it's time to do something with it. Choose the Edit | Copy Package command to place the package on the ClipBoard. Open Word for Windows (or WordPad if you don't have Word for Windows). Right-click the edit area and choose Paste from the object menu. You should see a display similar to Figure 12.14.

Figure 12.13. This is the simplest form of a completed package.

Figure 12.14. An object package looks and acts a lot different from its object counterpart.

This object package has several differences from the object you worked with before. The first difference is pretty obvious: There's no way to determine what the object looks like. This isn't the icon form of the package; it's a graphic representation of the package itself. You can double-click the package to bring up Paint, so at least that part of the package works satisfactorily. As you can see from Figure 12.15, however, Object Packager doesn't support in-place editing.

Figure 12.15. Even though this object package is embedded, it acts as if it were linked.



Note: You'll find a lot of limitations to using the Object Packager that fall outside the range of tasks you'd usually perform using it. You can't use packaged objects with ClipBook to create network links, for example. I doubt that anyone would even attempt this; any data distribution on the network will probably come from an OLE-equipped application. It's good to know what kind of limitations you can expect when using this product, however.

You don't have to use Object Packager this way. It does support other methods of creating an object package. Some of the methods work with certain kinds of software. The method I just described works with any kind of application, even if it doesn't support OLE. The only requirement is that the application support a command-line interface.

The preceding example did leave a little to be desired as far as capability goes. Try one more time to make a better package. Open HONEYCOMB.BMP (or any other BMP file) using Paint. Choose the Edit | Select All command to select the graphic and then copy it to the ClipBoard using Edit | Copy.

Open Object Packager. Choose the Edit | Paste command to copy the contents of the ClipBoard into the package area. Figure 12.16 shows the results. Notice how different this package appears from the first one. The problem with this method is that the originating application must support OLE as a client. Fortunately, it doesn't have to provide a specific level of support.

It's time to check the results of this second attempt at creating an object package. Choose the Edit | Copy Package command to place the package on the ClipBoard. Open Word for Windows (or WordPad if you don't have Word for Windows). Right-click the edit area and choose Paste from the object menu. You should see a display similar to Figure 12.17.

Figure 12.16. This method of creating an object package produces a different result from the previous method.

Figure 12.17. The new object package seems to produce the same results as before—an obvious limitation of Object Packager.

Notice that this object looks and acts the same as the previous object did. Even though the package looked like it would support in-place editing while it was in the Object Packager, it won't support it now. I wanted to point this out because it's a limitation of Object Packager rather than Paint or WordPad. It's a factor you need to remember whenever you resort to using Object Packager. Any objects you create using this method go from the client, through Object Packager, and to the originating application. If you want features such as in-place editing, you have to use an application that supports the feature directly rather than resort to the Object Packager. Remember that Object Packager was designed to help people gain some of the benefits of OLE even when using applications that didn't support it. In most cases, you'll want to leave this dusty tool where it belongs. It's still nice to know that it's there when you need it, though.

OLE Components


I previously mentioned that damage to the OLE information in a data file would prevent the objects you created from working properly. That's only part of the problem. You might also run into a situation where someone created a document using a newer version of the OLE system files than you did. With all the work Microsoft is doing with OLE, this is a very real possibility. (Usually, Microsoft will make the updated files available on CompuServe and their Internet server.)

Where do you find the OLE system files? You'll see a whole group of files in your \SYSTEM directory that provide support for OLE. The following list provides some details on the tasks each file performs. You can use this list if you ever run into a problem with corruption or you would simply like to know what level of support you can expect from a certain application. The presence or absence of these files might indicate problems with your installation as well. Missing OLE files means that you won't get the kind of support needed to make your system work efficiently.


On Your Own


Test the OLE capabilities of the various applications on your machine. Which ones support OLE as a client? Which ones support it as a server? Do you see any difference between the applications that support OLE 1 and OLE 2?

Use the various techniques I covered in this chapter for inserting an object in a container. Which methods do you find easiest to use? Why do you think some applications support one technique and others support another technique?

Try making an OLE link in a large document using an OLE 1 application. Make the same link using an OLE 2 application such as WordPad. Do you see a difference in the load time of the two documents? What additional features does WordPad provide that the OLE 1 application doesn't?

Open a copy of Explorer and use it to search your \SYSTEM folder. Can you find all the OLE-specific files installed on your system? What do the names of the various files tell you about those files' purposes?

Previous Page Page Top TOC Next Page